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Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension 


Abstract 


This document defines an extension to the Dynamic Link Exchange 
Protocol (DLEP) that enables the reporting and control of multi-hop 
forwarding by DLEP-capable modems. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8629. 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
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(https://trustee.ietf.org/license-info) in effect on the date of 
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1. Introduction 


The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. 
It provides the exchange of link-related control information between 
a modem and a router. DLEP defines a base set of mechanisms as well 
as support for possible extensions. This document defines one such 
extension. 


Some modem technologies support mobile ad hoc network (MANET) 
forwarding where connectivity to destinations is provided via 
forwarding in intermediate modems. This document refers to 
forwarding by intermediate modems as "multi-hop forwarding". DLEP 
Destination Messages can be used to report such reachable 
destinations (see [RFC8175]), but do not provide any information 
related to the number or capacity of the hops. The extension defined 
in this document enables modems to inform routers when multi-hop 
forwarding is being used and allows routers to request that modems 
change multi-hop forwarding behavior. The extension defined in this 
document is referred to as "Multi-Hop Forwarding", where each modem 
that transmits/sends data to reach a particular destination is 
counted as a hop. 


It is important to note that the use of the Hop Control mechanism 
defined in this document can result in connectivity changes and even 
loss of the ability to reach one or more destinations. The defined 
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mechanism will report such connectivity changes, but the details of 
what a router does or how it reacts to such are out scope of this 
document. 


This document defines a new DLEP Extension Type Value in Section 2, 
which indicates the use of the extension, and three new DLEP Data 
Items in Section 3. 


1.1. Key Words 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


2. Extension Usage and Identification 


The use of the Multi-Hop Forwarding Extension SHOULD be configurable. 
Per [RFC8175], to indicate that the extension is to be used, an 
implementation includes the Multi-Hop Forwarding Extension Type Value 
in the Extensions Supported Data Item. The Extensions Supported Data 
Item is sent and processed according to [RFC8175]. 


The Multi-Hop Forwarding Extension Type Value is 1 (see Section 5). 
3. Extension Data Items 


Three data items are defined by this extension. The Hop Count Data 
Item is used by a modem to provide the number of modem hops traversed 

to reach a particular destination. The Hop Control Data Item is used 

by a router to request that a modem alter connectivity to a 

particular destination. The Suppress Forwarding Data Item is used by 

a router to request that a modem disable multi-hop forwarding on 
ither a device or destination basis. 


3.1. Hop Count 


The Hop Count Data Item is used by a modem to indicate the number of 
modems that transmit/send data to reach a particular destination, 
i.e., hops, between the modem and a specific destination. In other 
words, each hop represents a transmission, and the number of hops is 
equal to the number of transmissions required to go from a router’s 
connected modem to the destination’s connected modem. The minimum 
number of hops is 1, which represents transmission to destinations 
that are directly reachable via the router’s locally connected modem. 
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The data item also contains an indication of when a destination that 
currently has a hop count of greater than one (1) could be made 
directly reachable by a modem, e.g., by reaiming an antenna. 


The Hop Count Data Item SHOULD be carried in the Destination Up, 
Destination Update, Destination Announce Response, and Link 
Characteristics Response Messages when the Hop Count to a destination 
is greater than one (1). 


A router receiving a Hop Count Data Item can use this information in 
its forwarding and routing decisions, but specific use is out of 
scope of this document. When using this extension, the absence of 
the Hop Count Data Item MUST be interpreted by the router as a Hop 
Count value of one (1). 


The format of the Hop Count Data Item is: 
0 1 2 3 


01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Data Item Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|P| Reserved | Hop Count | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Data Item Type: 21 

Length: 2 

P: 
The P-bit indicates that a destination is potentially directly 
reachable. When the P-bit is set, the router MAY request a direct 
link to the associated destination using the Hop Control Data Item 


described below. This field MUST be ignored when the valu 
contained in the Hop Count field is one (1). 


Reserved: 


The Reserved field MUST be set to zero by the sender (a modem) and 
ignored by the receiver (a router). 


Hop Count: 
The Hop Count is an unsigned 8-bit integer indicating the number 
of modem hops required (i.e., number of times a packet will be 


transmitted) to reach the destination indicated in the message. 
The special value of 255 (0xFF) is used to indicate that the 
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number of hops is an unknown number greater than one (1). This 
field MUST contain a value of at least one (1) if the associated 
destination is reachable. 


A value of zero (0) is used to indicate that the processing of a 
Hop Control action (see Section 3.2) has resulted in the 
destination no longer being reachable. A zero value MUST NOT be 
used in any message other than a Link Characteristics Response 
Message. 


Hop Control 


The Hop Control Data Item is used by a router to request a change in 
connectivity to a particular destination or to perform multi-hop 
processing on a device-wide basis. A router can request that a 
multi-hop-reachable destination be changed to a single-hop 
destination. A router can also indicate that the modem terminates a 
previous direct connectivity request to a particular destination. 


The Hop Control Data Item MAY be carried in a Session Update Message 
sent by a router when the control applies to the whole device, ora 
Link Characteristics Request Message when the control applies toa 
particular destination. 


A modem that receives the Hop Control Data Item in a Link 
Characteristics Request Message SHOULD take whatever actions are 
needed to make the change indicated by the data item for the 
associated destination Media Access Control (MAC) address. Once the 
change is made, fails, or is rejected, the modem MUST respond with a 
Link Characteristics Response Message containing an updated Hop Count 
Data Item. Note that other destinations can be impacted as a result 
of the change, and such changes are reported in Destination Down and 
Destination Update Messages. The modem MUST notify the router of 
each destination that is not identified in the Link Characteristics 
Response Message and is no longer reachable via a Destination Down 
Message. The modem MUST also notify the router of each impacted 
destination that is not identified in the Link Characteristics 
Response Message via a Destination Update Message. 


Failures may occur for multiple reasons, for example, the 
transmission characteristics of the link don’t support the one-hop 
connection at the time of the request. Requests can be rejected by 
local policy. 


A modem that receives the Hop Control Data Item in a Session Update 
Message SHOULD take whatever actions are needed to make the change 
indicated by the data item for all known destinations. Once the 
change is made, fails, or is rejected, the modem MUST respond with a 
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Session Update Response Message with an appropriate Status Code. The 
destination-specific impact of processing a Hop Control Data Item in 
a Session Update Message is provided via Destination Down and 
Destination Update Messages. The modem MUST notify the router of 
each destination that is no longer reachable via a Destination Down 
Message. The modem MUST notify the router of any changes in Hop 
Counts via Destination Update Messages. 


The format of the Hop Control Data Item is: 


0 1 2 3 

OP 2. BA 6 P89 Os 2s 3 OAs 6 Ts B09 OF a (23: SA Be 6 28.9 Oe 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ + 
| Data Item Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Hop Control Actions | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Data Item Type: 22 
Length: 2 
Hop Control Actions: 


The Hop Control Actions field is an unsigned 16-bit value with the 
following meaning: 


+------- +--------------------- + 
| Value | Action | 
+------- 4+--------------------- + 
| o | Reset | 
Ei | Terminate 

| 2 | Direct Connection | 
| 3 | Suppress Forwarding | 
+------- 4+--------------------- + 


Table 1: Hop Control Actions Values 


3.2.1. Reset 


The Reset Action requests that the default behavior be restored. 

When received in a Session Update Message, a modem MUST clear all 
control actions that have previously been processed on a device-wide 
basis and revert to its configured behavior. When received in a Link 
Characteristics Request Message, a modem MUST clear all control 
actions that have previously been processed for the destination 
indicated in the message. 
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.2. Terminate 


The Terminate Action is only valid on a per-destination basis and 
MUST NOT be sent in a Session Update Message. It indicates that a 
direct connection is no longer needed with the destination identified 
in the message. This request has no impact on multi-hop destinations 
and may fail even in a single-hop case, i.e., it can result in the 
Hop Count to the destination not being impacted by the processing of 
the request. 


3. Direct Connection 


The Direct Connection Action is only valid on a per-destination basis 
and MUST NOT be sent in a Session Update Message. It indicates that 
the modem SHOULD attempt to establish a direct connection with the 
destination identified in the message. This action SHOULD only be 
sent for destinations for which the Hop Count is both greater than 1 
and has the P-Bit set in the previously received Hop Count Data Item. 
Results of the request for the destination identified in the message 
are provided as described above. 


4. Suppress Forwarding 


The Suppress Forwarding Action is used by a router to indicate to its 
peer that multi-hop forwarding performed by the modem is to be 
suppressed. A router can request that multi-hop forwarding be 
suppressed on a device-wide or destination-specific basis. 


A modem that receives the Suppress Forwarding Data Item in a Session 
Update Message MUST suppress multi-hop forwarding on a device-wide 
basis. This means that data traffic originating from the modem’ s 
peer router SHALL only be sent by the modem to destinations that are 
one modem hop away, and that any data traffic received by the modem 
from another modem that is not destined to the peer router SHALL be 
dropped. The impact on destination hop counts are provided to the 
router by the modem as described above. 


A modem that receives the Suppress Forwarding Data Item in a Link 
Characteristics Request Message MUST suppress multi-hop forwarding 
for only the destination indicated in the message. This means that 
data traffic originating from the modem’s peer router SHALL be sent 
by the modem to the destination indicated in the Link Characteristics 
Request Message only when it is one modem hop away. Notably, data 
traffic received by the modem from another modem can be forwarded by 
the modem per its normal processing. Results are provided as 
described above. 
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4. Security Considerations 


The extension defined in this document enables the reporting and 
control of forwarding information by DLEP-capable modems. The 
extension does not inherently introduce any additional 
vulnerabilities above those documented in [RFC8175]. The approach 
taken to security in that document applies equally when running the 
extension defined in this document. 


The extension does define one mechanism that is worth particular 
note. It includes a Hop Control mechanism (see Section 3.2) that is 
similar to the Link Characteristics Request Message defined in 
[RFC8175] in that it can impact the set of destinations reported as 
reachable. With the Link Characteristics Request Message, this risk 
is implicit. With the Hop Control mechanism defined in this 
document, it is more likely. From a security perspective, 
implementations should be aware of this increased risk and may choose 
to implement additional configuration control mechanisms to ensure 
that the Hop Control mechanism is only used under conditions intended 
by the network operator. 


Implementations of the extension defined in this document MUST 
support configuration of TLS usage, as described in [RFC8175], in 
order to protect configurations where injection attacks are possible, 
i.e., when the link between a modem and router is not otherwise 
protected. 


Note that this extension does allow a compromised or impersonating 
modem to suppress transmission by the router or a switch that 
interconnects the modem and router. Similar attacks are generally 
possible for DLEP, for example, an impersonating modem may cause a 
session reset or cause a compromised modem to simply drop all traffic 
destined to, or sent by, a router. [RFC8175] defines the use of TLS 
to protect against the impersonating attacker. 


5. IANA Considerations 


As described below, IANA has assigned 3 values to registries defined 
by [RFC8175] and created a new registry. 


5.1. Extension Type Value 


IANA has registered the following new value in the Specification 
Required range of the "Extension Type Values" registry within the 
"Dynamic Link Exchange Protocol (DLEP) Parameters" registry. 
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4+------ 4+---------------------- + 
| Code | Description 

4+------ 4+---------------------- + 
| 1 | Multi-Hop Forwarding | 
+------ 4+---------------------- + 


Table 2: Requested Extension Type Value 
5.2. Data Item Values 
IANA has registered the following 2 values in the Specification 


Required range of the "Data Item Type Values" registry within the 
"Dynamic Link Exchange Protocol (DLEP) Parameters" registry. 


+----------- +------------- + 
| Type Code | Description | 
+----------- +------------- + 
| 21 | Hop Count | 
| 22 | Hop Control | 
+----------- +------------- + 


Table 3: Requested Data Item Values 
5.3. Hop Control Actions Registry 


IANA has created the "Hop Control Actions Values" registry within the 
"Dynamic Link Exchange Protocol (DLEP) Parameters" registry. The 
following table provides initial registry values and the registration 
procedures [RFC8126] that apply: 


+------------- 4+------------------------ + 
Value Action/Policy 
+------------- +------------------------ + 
0 Reset 
1 Terminate 
2 Direct Connection 
3 Suppress Forwarding 
4-65519 Specification Required 
65520-65534 Private Use 
65535 Reserved 
+------------- 4+------------------------ + 


Table 4: Hop Control Actions Values 
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